Vibe Coding：AI 輔助編程速成
「Vibe Coding」= 以 AI 助手／代理 為主體、用自然語言驅動程式開發；重點不在手寫語法，而在用清晰意圖 + 快速迭代把 MVP 拉起來，同時用測試與審查把風險壓住。這個詞近年由 Karpathy 帶火，主流平台（Replit、Microsoft Learn 等）已有入門模組；同時也有媒體對「只憑 vibe 而不審碼」提出質疑。
甚麼是Vibe Coding
💡 定義
Vibe Coding 並非「只憑感覺寫程式」，而是一種以 AI 代理（Agent / LLM）為協作核心的新式編程工作流。 在這種模式下：
人類的角色：負責「說明需求、設定限制、撰寫驗收條件」。
AI 的角色：根據這些描述生成、修改或測試程式碼。
換句話說，Vibe Coding = 描述 + 驗收導向的開發流程， 而不是傳統「從零開始手寫語法」的編程。
⚠️ 風險提醒與專業責任
Vibe Coding 近年成為熱門詞彙，但許多報導也指出其潛在誤導與風險：
🚫 誤解 1：Vibe Coding = 不用看程式
錯。AI 生成的代碼只是草稿，仍需人工閱讀、理解與測試。
真正的專業在於：你是否能判斷這段代碼是否安全、合理、可維護。🔍 誤解 2：AI 生成程式一定正確
實際上，LLM 會出現「幻覺」（Hallucination）或腳位錯誤、邏輯漏洞。
因此必須進行 三道關卡：✅ 測試 (Testing)：確認功能正確與邏輯一致。
✅ 審查 (Review)：人工逐行檢查程式註解與腳位。
✅ 授權 (License Check)：確認 AI 是否引用外部程式碼或開源庫。
⚙️ 誤解 3：AI 可以完全取代工程師
現階段 AI 仍依賴人類提供明確需求（Prompt Engineering），
若需求模糊，AI 可能生成錯誤或危險代碼。
因此，Vibe Coding 是「共同創作」而非「全自動化」。
方法論（PRD → Prompt → Agent）
🧩 Prompt 對比示例：低配版 vs 專業版
🚫 差的 Prompt（學生常犯例子）
整一個呼吸燈。
❌ 問題分析
| 問題 | 為什麼唔得 |
|---|---|
| 🎯 目標太模糊 | 「整一個呼吸燈」可以有十種解讀：ESP32？Arduino？用 PWM？用 delay？AI 唔知道。 |
| ⚙️ 缺少技術細節 | 無講腳位、無講亮度範圍、無講週期長短、無講需唔需要平滑效果。 |
| 🧪 無驗收標準 | 「呼吸」有幾快先算呼吸？AI 無法測試或優化。 |
| 📦 無限制條件 | AI 可能亂用 delay()、亂用外部函式庫，導致程式卡死。 |
| 🔁 無法迭代 | 因為前面無明確條件，學生後面講「慢啲啦」AI 只會亂調。 |
🧨 結果：AI 可能生成一個閃爍燈（Blink）， 而唔係真正亮暗平滑嘅「呼吸燈」。 學生睇落以為「好似啱」，但實際邏輯錯晒。
✅ 標準 Prompt（可直接使用）
你是一名嵌入式系統工程師。
請為 ESP32 生成一個可在 Arduino IDE 執行的程式。
功能如下：
控制一顆 LED（接在 GPIO 2 腳位）
LED 亮度需平滑地由暗變亮，再由亮變暗，形成「呼吸效果」
一個完整週期約 2 秒
必須使用 PWM (analogWrite) 控制亮度，不得使用
delay()用
millis()控制時間，使主程式可持續運行不使用外部函式庫，程式需在單一
.ino檔案完成請加入清晰註解，說明每段邏輯
在最後加入一個測試函式，用以改變呼吸速度並列印結果
✅ 為什麼呢個好？
| 關鍵元素 | 說明 |
|---|---|
| 角色明確 | 告訴 AI 佢係嵌入式工程師，代碼風格會自動變專業。 |
| 目標具體 | 「平滑亮暗」+「週期 2 秒」= 可驗證、可測試。 |
| I/O 清楚 | 指定 GPIO 腳位，AI 唔會亂用。 |
| 限制明確 | 禁止 delay()、禁止外部函式庫。 |
| 驗收條件 | 可以量化結果，方便檢查與 debug。 |
| 結構化思維 | 用清單分段，AI 會按邏輯生成乾淨 code。 |
PDR(Prompt Requirements Document)
Prompt Requirements Document (PRD): A New Concept for the Vibe Coding Era
這篇文章介紹了一個名為「提示詞需求文件 (Prompt Requirements Document, PRD)」的新概念，它是在「Vibe Coding Era)」中，因應人類與 AI 協作開發軟體所誕生的。
簡單來說：
💡 核心觀念：提示詞需求文件 (PRD)
傳統 PRD：主要處理非結構化資訊，用於人類對人類的對齊。
新的 PRD (提示詞需求文件)：專注於生成、編輯和管理結構化的提示詞（包括文字、圖片、影片等），這些提示詞必須是AI 和人類都能理解和有效使用的。
目的：成為人類與 AI 共同理解專案、保持一致性的關鍵橋樑和唯一事實來源。
🛠 內容三大支柱
一個精心編寫的提示詞 PRD 通常包含三個部分：
《指南 (Guideline)：共享 AI-人類理解》
一個全面的知識庫，建立專案背景、技術原理和架構決策。
確保 AI 助理和人類團隊成員從相同的理解基礎上運作，類似於傳統 PRD 讓所有利害關係人對齊需求。
《指導 (Guidance)：提示詞演進方法論》
一種結構化的方法，幫助開發者將抽象概念演變為 AI 系統能準確解釋和執行的精確指令。
包括帶註解的提示詞範例、模式庫、情境最佳實踐和常見錯誤警告，讓新手也能建立有效、高品質的提示詞。
《護欄 (Guardrails)：AI 輔助程式碼審查》
一套明確定義的自動化評估標準和品質檢查點，專門針對已知的專案風險和常見痛點。
讓 AI 系統能對程式碼進行初步審查，在人工審查前就找出基本問題，減輕人類審查的負擔，確保程式碼品質一致。
🧩 PRD 結構化 Prompt 組成
| 組成元素 | 應包含內容 | 說明（為何重要） | 示例（以 ESP32 呼吸燈為例） |
|---|---|---|---|
| 1. 🎭 角色 (Role) | 指定 AI 的身份、專業角色 | 令 AI 採用正確語氣與知識框架，減少幻覺 | 「你是一名嵌入式系統工程師。」 |
| 2. 🎯 目標 (Goal) | 明確任務目的與要達成的效果 | 讓 AI 理解最終成果，而非只執行片面動作 | 「請為 ESP32 生成一個 Arduino IDE可執行的呼吸燈控制程式。」 |
| 3. 🔌 輸入 / 輸出 (I/O) | 清楚列出輸入來源、資料類型、輸出格式 | 幫 AI 知道該讀取／輸出的內容與型態 | 「輸入：無（自動執行）；輸出：LED PWM 亮度變化（0–255）」 |
| 4. ⚙️ 限制 (Constraint) | 指定開發條件、不可做的事、技術邊界 | 限制範圍可令 AI 生成安全、可測試、可重現的結果 | 「不得使用 delay()；不可用外部函式庫；單一 .ino 檔完成。」 |
| 5. 🧪 驗收標準 (Acceptance Tests) | 寫出 3–5 條可測試條款（PASS / FAIL） | 學習用「測試」思維驗證 AI 代碼品質 | 「LED 每 2 秒完成一次呼吸週期；變化平滑無閃爍；含註解說明邏輯。」 |
| 6. 🔁 迭代規則 (Iteration Rule) | 定義 AI 應如何修正或優化 | 應理解 Vibe Coding 不會一次到位，而是多輪調整 | 「若亮暗變化太突兀，請 AI 調整 PWM 步進值或更新間隔。」 |
| 7. 🧷 授權與註解 (License / Comments) | 要求列出 AI 工具、作者及程式註解 | 建立資料倫理與透明開發習慣 | 「請在程式結尾註明作者與生成工具名稱。」 |
Prompt ≠ 句子，而是結構： 要學懂「講清楚」，不是「講多啲」。
Role + Goal = Context；Constraint + Test = Guardrail： 結構化 prompt 就是為 AI 建立「任務邊界」。
同一個任務，不同結構 → 不同結果： 學懂比較「差 prompt」與「結構化 prompt」輸出差異。
非常重要
Vibe coding 不是「不寫程式」；是把人力投到定義問題、驗收與風險，把低層繁瑣交給代理。
真實世界可交付，靠的是清晰 PRD + 可重複測試 + 審查習慣，而不是「接受所有建議」。
🧾《Vibe Coding 結構化 Prompt 練習 》
ESP32 呼吸燈
幫我整一個 ESP32 紅綠燈程式
ESP32有線搶答機
(Bonus)為有線搶答機，加入蜂鳴器，報聲時系統照常能復原和搶答
工作紙